fix(l2gersync): adapt isGERRemovedFromL2 scan to RPC eth_getLogs block-range cap - #1813
Merged
Merged
Conversation
isGERRemovedFromL2 scan to RPC eth_getLogs block-range cap
…ge cap isGERRemovedFromL2 scanned for the GER removal event from the insert block (which can be arbitrarily far behind the head) to "latest" in one open-ended eth_getLogs call. Once the chain advanced past the RPC provider's block-range cap, that call failed with "query exceeds max block range N" on every single appender retry, logging an ERROR forever and never actually recovering a genuinely-removed GER. scanRemovedGERs now parses that error via ParseMaxRangeFromError and retries chunked - the same adaptive, config-free pattern already used by L2EVMGERReader.GetRemovedGERsForRange and AgglayerBridgeL2Reader's fetchUnsetClaimsWithFallbackChunking/getUnsetClaimsInChunks - caching the learned cap (removalScanMaxRange) so later retries skip the doomed unbounded call, and recursing per-chunk (fetchRemovedGERsChunk) so a chunk that is itself still too large keeps adapting. Closes #1812 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
joanestebanr
force-pushed
the
fix/l2gersync-max-block-range-1812
branch
from
September 1, 2026 08:23
7f3e35d to
3583743
Compare
joanestebanr
enabled auto-merge (squash)
September 1, 2026 08:25
arnaubennassar
approved these changes
Sep 1, 2026
joanestebanr
disabled auto-merge
September 1, 2026 10:27
joanestebanr
enabled auto-merge (squash)
September 1, 2026 10:27
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🔄 Changes Summary
isGERRemovedFromL2scanned for a GER'sUpdateRemovalHashChainValueremoval event from the insert block (which can be arbitrarily far behind the head) to "latest" in a single open-endedeth_getLogscall.query exceeds max block range Non every single appender retry, logging an ERROR forever and never actually recovering a genuinely-removed GER.scanRemovedGERsnow parses that error viaaggkitcommon.ParseMaxRangeFromErrorand retries chunked — no config parameter involved, the same adaptive pattern already used byL2EVMGERReader.GetRemovedGERsForRangeandAgglayerBridgeL2Reader.fetchUnsetClaimsWithFallbackChunking/getUnsetClaimsInChunks.removalScanMaxRangeso that, once learned, later retries skip straight to the chunked path instead of repeating the doomed unbounded call.fetchRemovedGERsChunkrecurses per-chunk (mirroring those siblings) so a chunk that is itself still too large keeps adapting instead of failing the whole scan outright.downloaderSovereign.scanRemovedGERs/fetchRemovedGERsChunk).📋 Config Updates
✅ Testing
TestDownloaderSovereign_IsGERRemovedFromL2_RecoversFromMaxBlockRangeError(reproduces the max-range error and verifies the chunked recovery combines results across chunks) andTestDownloaderSovereign_IsGERRemovedFromL2_CachesLearnedMaxRangeAcrossCalls(proves a second call skips the doomed unbounded call once the cap is learned). Fulll2gersyncsuite green,go vetclean,golangci-lint0 issues.bali-82-opbridge-service node whoseL1InfoTreeSyncwas still far behind head — the unbounded scan was failing every retry with this exact error; confirmed the chunked fallback resolves it.🐞 Issues
isGERRemovedFromL2fails, error:failed to scan for GER removal events from block n: query exceeds max block range 100000#1812🔗 Related PRs
isGERRemovedFromL2.📝 Notes